Currently, many commercial and non-commercial entities, such as insurance companies, financial services companies, government agencies, etc., provide interactive forms that users (e.g., customers) may conveniently access via the Internet using a web browser. For example, a company or other entity may provide registration forms, application forms, insurance claim forms, change of address forms, refund request forms, complaint forms, etc. Indeed, some companies require hundreds or even thousands of different interactive forms for a wide variety of purposes. A form is generally “interactive” in the sense that a user may enter information into various fields of the form and, for some forms, receive feedback based on those entries (e.g., to indicate an invalid entry). As business needs dictate, different interactive forms may be developed using different types of vendor tooling and/or file formats. For example, some forms may be created in a PDF format using Adobe tooling, other forms may be created in a PDF, HTML, or XML-based format using Hewlett-Packard tooling, other forms may be created in a PDF, HTML, or XML-based format using Thunderhead tooling, etc.
The file format and vendor tooling used to create and view a form may dictate the “look and feel” of the form when accessed by a user via a web browser, as well as the interactive functionality/features that the form provides. Moreover, the idiosyncrasies of the individuals designing the various forms may result in substantial differences in the look, layout and/or functionality/features of different forms. Any or all of these factors may cause a user's experience to vary significantly depending upon which form he or she accesses, which may in turn lead to user confusion. For example, different forms may present buttons for the same action with a different label, a different appearance, and/or a different location. Moreover, identically labeled form action buttons (e.g., “submit,” “clear,” etc.) might cause different results for different forms depending upon the manner in which each form implements the action. For example, clicking a “submit” button in a first form may cause a pop-up window to appear requesting the user to confirm the submission, while clicking a “submit” button in a second form may cause the form entry information to be posted to a server without requesting user confirmation. A user may also be confused as to the source of forms, or view forms as “unprofessional,” if ancillary information included on the forms (e.g., company name/logo, contact information, web links to other company information, etc.) differs from form to form in terms of appearance, location and/or content.
In addition to providing an inconsistent user experience and possible user confusion, the conventional approach to providing forms may be very costly/inefficient when a change must be implemented across a large number of forms. For example, changing a company logo included on hundreds or thousands of different forms generally requires each of those forms to be individually modified. As another example, if certain aspects of a particular type of vendor tooling were to change due to a software update, all of the forms created using that vendor tooling might require individual coding modifications.